Data backup, recovery, and migration for Kubernetes

This page describes how to back up and recover Data Control Tower (DCT) in Kubernetes environments, as well as how to migrate between clusters or to a DCT appliance. The script-based backup supports lift-and-shift and blue-green deployment strategies, as well as one-off migration scenarios. The two DCT installations are referred to as source (initial environment) and target (destination environment).

Choose your backup approach

DCT on Kubernetes supports two backup approaches. Choose based on your recovery needs:

Approach

Best for

What it captures

Portability

Kubernetes-native volume snapshots (CSI / Velero / cloud provider tools)

Fast recovery within the same cluster or storage backend. Captures all persistent state in a single coordinated snapshot.

All DCT persistent volumes — PostgreSQL database, encryption keys, application state.

Tied to your storage backend and cluster. Cannot restore to a different cluster type or to an appliance.

Script-based backup (backup_restore.sh)

Migrating to a different cluster, a different namespace, or to an appliance. Maintaining portable, off-cluster backups. Blue-green or lift-and-shift deployments.

Full PostgreSQL database (all DCT application data) and encryption keys — accounts, passwords, access groups, engine registrations, dSource/VDB metadata, compliance configurations, bookmarks, operation history. Does not include Helm chart configuration (certificates, hostname, resource limits).

Portable across any DCT Kubernetes or OpenShift installation. Can also be used to restore to a DCT appliance.

Delphix recommends configuring at least one of these approaches at installation time. If your cluster already uses a backup tool like Velero or a cloud provider's managed backup service, extending that coverage to the DCT persistent volumes is the simplest path.

Support notice: Delphix supports the script-based backup solution described on this page. Kubernetes-native volume snapshot approaches (CSI drivers, Velero, cloud provider backup tools) are third-party solutions. Delphix can provide general guidance on which volumes must be protected, but cannot provide direct support for configuring or troubleshooting those tools. Refer to your platform and tool vendor documentation for assistance.

If you are using an external database, Kubernetes-native snapshots must still capture the encryption key volumes (gateway-data, masking-data, virtualization-app-data), and the external database must be backed up separately using your database provider's tooling. See External database support for details.

Script-based backup

The following prerequisites, backup steps, restore steps, and additional environment configuration all apply to the script-based backup approach (backup_restore.sh).

Prerequisites

The following prerequisites apply to the script-based backup and restore process:

  1. The source DCT server must be operational.

  2. The target DCT installation must be deployed in a separate Kubernetes cluster.

    Note: A separate cluster is required to avoid conflicts in networking, service discovery, and persistent volume claims that may arise when running two DCT instances within the same cluster. This isolation helps ensure clean separation of environments during migration and recovery operations.

  3. Both source and target must run DCT version 2025.2.0.0 or later. Script-based backup and restore is only supported from version 2025.2.0.0 onward.

  4. The target must not run an earlier DCT version than the version that created the backup.

  5. For a backup created before the PostgreSQL 18 upgrade, the target must run DCT 2026.5.0. The target database image must contain the migration script, and the automated database migration step must be enabled.

  6. Backup files must be shareable between the source and target environments.

  7. You must have sufficient access to run kubectl (or oc) commands in both clusters.

  8. All required DCT services must have a running, reachable container. Resolve unavailable services and restart loops before starting a restore. The AI control and AI execution services are optional.

Backup steps

  1. Download the dct-support-tools tarball from the Delphix download site.

  2. Extract the tarball and navigate into the backup-restore directory. Key files include:

    1. backup_restore.sh

    2. appliance_backup_restore.sh

    3. A README with version-specific details.

  3. Transfer the backup_restore.sh script to a host that has kubectl access to the DCT pods. Required tools include:

    1. bash

    2. tar

    3. zip and unzip

  4. Make sure the source DCT Kubernetes cluster is active and run:

    Copy 
    /bin/bash backup_restore.sh -n <namespace> > dct-backup.zip

    Replace <namespace> as needed (defaults to dct-services). Output is typically silent on success. The backup size usually ranges from 1 GB to 10 GB and takes a few minutes to complete. This backup file contains all the necessary information to restore your DCT install in the new environment, except for the environment configuration information.

Restore steps

Before restoring, transfer the backup file (dct-backup.zip) to a host with access to the target Kubernetes cluster. If your source and target environments are within the same cluster (but using different namespaces), make sure the script is executed from a context that targets the correct namespace.

Once the file is in the correct environment, run the restore command:

Copy 
/bin/bash backup_restore.sh -n <namespace> -r dct-backup.zip

Replace <namespace> with the target DCT namespace (defaults to dct-services if not specified).

Before changing the target installation, the tool verifies that the required services are reachable and that the backup is compatible with the target. The tool does not modify the installation if a compatibility or preflight check fails.

A same-version restore typically completes within a few minutes. A restore from a PostgreSQL 14 backup to DCT 2026.5.0 runs an automatic database conversion that can take approximately 15 to 90 minutes. The tool might not display progress during the conversion.

Restore a backup created before the PostgreSQL 18 upgrade

DCT 2026.5.0 is the bridge release for backups created before the PostgreSQL 18 upgrade. To prepare such a backup for use with a later DCT release:

  1. Deploy or upgrade the target installation to DCT 2026.5.0.

  2. Confirm that all required DCT services are running and reachable.

  3. Restore the backup by using the preceding restore command.

  4. Allow the automatic database conversion and ordered service restart to finish. This process can take approximately 15 to 90 minutes without displaying progress.

  5. Verify that the restored DCT installation is operational.

  6. Create a new backup from DCT 2026.5.0. Use this backup when restoring to a later DCT release.

Recover from a failed restore

Read the failure message before running the restore again. The message describes the state of the installation and provides the appropriate recovery action:

  • If the database was not replaced, correct the reported problem and run the restore again. The original database remains intact.

  • If the database was replaced, do not run the restore again. Follow the recovery instructions in the message, including any steps to restart services or clear maintenance mode.

AI provider credentials

New backups include the AI control service encryption key, so stored AI provider credentials survive a restore. The backup and restore tool skips the AI control and AI execution services when they are not deployed.

Backups created before AI encryption key support do not contain this key. Re-enter the AI provider credentials after restoring one of these backups.

In a migration scenario from a Kubernetes DCT deployment to a DCT appliance VM deployment, use these restore steps.

Additional environment configuration

The DCT Helm chart values.yaml file includes configuration settings such as certificates, hostname, and resource limits. They are critical to ensure your installation is secure and performant. These values are not managed by the restore process and must be managed manually. You may update this file either before or after the migration.

It is recommended that you configure these values as expected before beginning the migration process to minimize downtime.

Kubernetes-native volume snapshots

In addition to the script-based backup described above, Kubernetes-native volume snapshot capabilities can be used to back up DCT persistent data. This approach uses your cluster's CSI (Container Storage Interface) driver and the Kubernetes VolumeSnapshot API to capture all DCT persistent volumes as a coordinated group in a single snapshot operation.

Which volumes to capture

The following DCT persistent volumes must all be included in the snapshot. Your backup tool should capture these together in a single snapshot operation to ensure consistency:

Persistent volume

Contents

Required?

gateway-data

Encryption key for sensitive application data

Yes — without this, database backups cannot be decrypted

masking-data

Encryption key for masking service data

Yes

virtualization-app-data

Encryption key for virtualization service data

Yes

gwdatabase-data

PostgreSQL database (all DCT application metadata)

Yes, unless using an external database

If you are using an external database, the gwdatabase-data volume is not used by DCT. Instead, back up the external database using your database provider's backup tooling. The encryption key volumes (gateway-data, masking-data, virtualization-app-data) must still be captured. A database backup without the corresponding encryption key backups cannot be restored.

The encryption keys in gateway-data, masking-data, and virtualization-app-data do not change after initial creation. They do not need to be snapshotted on the same schedule as the database, but must be available at restore time.

Tooling

Any Kubernetes-native backup tool that supports VolumeSnapshots can be used, including:

  • Kubernetes VolumeSnapshot API (requires a CSI driver that supports snapshots): Kubernetes VolumeSnapshots documentation

  • Velero (backup and restore for Kubernetes resources and persistent volumes): Velero documentation

  • Cloud provider tools such as AWS Backup for EKS, Azure Backup for AKS, or GCP Backup for GKE

Refer to your CSI driver and cloud provider documentation for snapshot scheduling and retention configuration.

When to use the script-based backup instead

The script-based backup described above produces a portable backup file that can be restored to any DCT Kubernetes installation (or migrated to an appliance). Volume snapshots are tied to the storage backend and cluster. If you need cross-cluster or cross-platform portability, use the script-based approach.

Example deployment scenarios

An example of a lift and shift deployment could be:

  1. Backup the running source server pre-upgrade.

  2. Upgrade the source server to the desired version and confirm functionality.

  3. Backup the source server post-upgrade.

  4. Install a new target server as the same source server's post-upgrade version.

  5. Restore the source post-upgrade backup to the target server.

  6. Restart the target services and confirm functionality.

  7. Shutdown the source server or maintain it for further testing.

An example of a blue-green deployment could be:

  1. Backup the running source server.

  2. Install a new target server with the same source server's version.

  3. Restore the source backup to the target server.

  4. Restart the target services and confirm functionality.

  5. Upgrade the target server to the newer version and confirm functionality.

  6. Redirect traffic to the target server.

  7. Shutdown the source server or maintain it for a future blue-green deployment.